System and method for processing telephony sessions

ABSTRACT

In one embodiment, the method of processing telephony sessions includes: communicating with an application server using an application layer protocol; processing telephony instructions with a call router; and creating call router resources accessible through a call router Application Programming Interface (API). In another embodiment, the system for processing telephony sessions includes: a call router, a URI for an application server, a telephony instruction executed by the call router, and a call router API resource.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 12/417,630, filed 2 Apr. 2009, which claims the benefit of U.S.Provisional Application No. 61/041,829 filed 2 Apr. 2008; U.S.Provisional Application No. 61/055,417 filed on 22 May 2008, U.S.Provisional Application No. 61/100,578 filed on 26 Sep. 2008, U.S.Provisional Application No. 61/156,746 filed on 2 Mar. 2009, and U.S.Provisional Application No. 61/156,751 filed on 2 Mar. 2009, which areall incorporated in their entirety by this reference.

TECHNICAL FIELD

This invention relates generally to the telephony field, and morespecifically to a new and useful system and method for processingtelephony sessions in the telephony field.

BACKGROUND

In the last decade, legislation and the advent of Voice over InternetProtocol (VOIP) have revolutionized the communication industry with newtechnologies, business models, and service providers. Software andcommodity hardware now provide an alternative to expensive carrierequipment. One can implement extensible call switching and voiceapplication logic in Open source software applications, such as Asteriskand FreeSwitch. These new application stacks, however, usher in newcomplexities and challenges, requiring new skill sets to deploy,develop, and maintain. Deploying telephony services requires knowledgeof voice networking and codecs, hardware or services to bridge serversto the public phone infrastructure, capital investment in hardware, andongoing collocation of that hardware. These burdens are a mereprerequisite to developing the actual application, which requiresdevelopers to train in new languages, tools, and developmentenvironments. Even telephony applications that currently try to leveragea model more similar to web-development such as Voice Extensible MarkupLanguage (VoiceXML), require the dedication to learn a new language andunderstand telephony interaction. Ongoing operation and maintenance ofthese services requires teams to adopt new analysis tools, performancemetrics, and debugging methodologies. Developing even the simplest ofvoice services (such as a so-called “phone tree”) requires significantupfront and ongoing investment in specialized infrastructure, skills,and operations. Thus, there is a need in the telephony field to create anew and useful system and method for processing telephony sessions. Thisinvention provides such a new and useful system and method.

SUMMARY

The method of the preferred embodiment for processing telephony sessionsinclude the steps of communicating with an application server using anapplication layer protocol, processing telephony instructions with acall router, and creating call router resources accessible through anApplication Programming Interface (API). The method and system of thepreferred embodiments enables web developers to use their existingskills and tools with the esoteric world of telephony, making telephonyapplication development as easy as web programming. The method andsystem use the familiar web site visitor model to interact with a webdeveloper's application, with each step of the phone call analogous to atraditional page view. Within this model, developers reuse theirexisting tools and techniques, including familiar concepts such as HTTPredirects, accessing resources through an API, cookies, and mime-typeresponses to construct complex telephony applications. The method ofprocessing telephony instructions and creating call router resourcesaccessible through an API (a call router API) cooperatively function toenable a stateless and simple telephony language with more call routerresources and information provided through the call router (preferably aREST API as is familiar to many web developers). In one embodiment, thetelephony instructions set may have fewer than dozen verbs, simplifyingthe language so that developers can quickly learn and implementtelephony applications, while the call router API compliments the simpletelephony instructions to enable complex telephony applications.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a flowchart representation of a preferred method of theinvention.

FIGS. 2A, 2B, 3A and 3B are schematic representations of preferredembodiments of the invention.

FIGS. 4A-4C are examples of a HTTP GET request, a HTTP POST request, anda HTTP GET request, respectively.

FIGS. 4D-4F are examples of a HTTP requests.

FIGS. 5A and 5B are examples of XML responses.

FIG. 6 is an example of a call Router request and response.

FIGS. 7-15 are schematic representations of various applications thatincorporate the principals of the preferred method of the invention.

FIG. 16 is a flowchart representation of the sub-steps relating to thedigital signature aspect of the preferred method of the invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of the preferred embodiments of the inventionis not intended to limit the invention to these preferred embodiments,but rather to enable any person skilled in the art to make and use thisinvention.

1. Method for Processing Telephony Sessions

As shown in FIGS. 1, 2A, 2B, 3A, and 3B, the method 10 of the preferredembodiment for processing telephony sessions include the steps ofcommunicating with an application server using an application layerprotocol S110, processing telephony instructions with a call routerS120, and creating call router resources accessible through anApplication Programming Interface (API) S130. The preferred method mayalso include other steps and/or sub-steps, as explained below.

1A. Communicating with an Application Server

As shown in FIG. 1, the step of communicating with an application serverusing an application layer protocol Silo preferably includes thefollowing sub-steps: initiating a telephony session S1, mapping a callto a Universal Resource Identifier (URI) S3, sending a request to aserver associated with the URI S5, processing the request correspondingto the state of a telephony session S7, and receiving a response fromthe server S9. One of the challenges of using the familiar web sitevisitor model is that a third party web application may expose URIs thatcontain sensitive data or that suggest actions that could maliciouslymanipulate the application database. In the preferred embodiment, thecall router cryptographically signs outbound requests to customer webapplications using an account-specific key. More specifically, the stepof communicating with the application server includes the additionalsteps of digitally signing the request parameters S4 and verifying thedigital signature of the request parameters S6. Only the call router andthe application server know that key, so any request that includesparameters (URL, POST data, headers, etc) signed with that key can bechecked for authenticity before allowing such operations. This methodalso provides verification of authenticity over insecure links (HTTP)with low CPU overhead.

Step S1, which recites initiating a telephony session, functions toaccept an incoming message. The message is preferably a call from aPSTN-connected (Public Switched Telephone Network) or Internetaddressable devices, such as landline phones, cellular phones, satellitephones, Voice-Over-Internet-Protocol (VOIP) phones, SIP devices, Skype,Gtalk, or any other suitable PSTN-connected or Internet addressablevoice device. The message may alternatively be a Short Message Service(SMS) message. A SMS gateway server may alternatively connect to a SMSnetwork through a Short Message Service Center (“SMS-C”), directly tothe Signaling System #7 (SS7) telephony network, or by any othersuitable SMS gateway provider, and the message is preferably receivedfrom the gateway by the call router and translated into a format (suchas a URI) that can be sent over the public Internet such as HTTP, basedon the recipient address of the SMS, such as a short code, or DirectInward Dialing (DID), or other suitable unique recipient identifier. Themessage may alternatively be a multimedia message, a facsimiletransmission, an email, or any other suitable messaging medium. Theoriginating phone number of the PSTN device is preferably captured usingcaller ID, but any other suitable ID may be captured, such as a VOIPprovider ID, SMS device number, email address, or a short code. Thedialed phone number, the EIN, and/or billing identifier, and/or the dateand time of the call are also preferably included in the sessioninformation. An authentication ID may additionally or alternatively beincluded in the session information.

In one variation, Step S1 also functions to initiate a telephony session(such as a phone call) via an HTTP or other request sent to a callrouter from an application running on a third-party server. In thisvariation, the application running on the server preferably specifies aninitial URI for the call router to use for telephony session in step S3,as well as the phone number (or other addressable destination) to dialand the source phone number (caller id). In this variation, the callrouter API is preferably used by the application server to request anoutgoing call from the call router.

Step S3, which recites mapping the call to a Universal ResourceIdentifier (URI), functions to enable a telephony session to beconverted into a format that may be handled with standard web serversand web applications. The mapping is preferably performed using a callrouter. The initial URI is preferably pre-specified at the call routerby a web application (which may be running on a third party server) orcall router account owner. More preferably, the initial URI is assignedto the call via a unique identifier for the call destination, such as aDID (Direct Inbound Dial) phone number, or a VOIP SIP address. The URImay alternatively be specified by a remote server or other suitabledevice or method. In one variation, the URI may be used to encapsulatestate information or a portion of state information from the initiatedtelephony session, such as the originating phone number, the dialedphone number, the date and time of the call, geographic location of thecaller (e.g. country, city, state, and/or zip), and/or the unique callID. The information included in the URI may be included in the form of aURI template. For example the URI default template could be:http://demo.twilio.com/myapp/{dialed phone number}/{originating phonenumber} or http://demo.twilio.com/myapp/foo.php?dialed_number={dialedphone number}& originating_number={originating phone number}.

Step S4 functions to digitally sign the request parameters. As shown inFIG. 16, Step S4 preferably determines the call router account ownerand, more preferably, looks up the account owner's unique ID or secretkey and signs a set of request parameters. Step S4 is preferablyaccomplished by generating a cryptographic hash of the requestparameters, preferably including the URI as well as any request bodyparameters (in the case of an HTTP POST, for example) with the uniquekey associated with the call router account owner. The cryptographichash is preferably generated by appending the hash of the requestparameters to the original set of request parameters. The hash ispreferably appended to a URL, but if the hash is particularly long (i.e.for a very large number of parameters) the hash may be included in anHTTP header, where there is no limitation on size. In a variation ofStep S4, at least one sensitive parameter may be individually encryptedusing the account owner's secret key before the hash is processed. Inanother variation, a cryptographic credential delegation system, such asOauth (oauth.net), may alternatively be used to electronically sign therequest.

Step S5 functions to send the request to a server. Preferably, therequest is sent to a URI and, more preferably, the request is sent tothe URI mapped in S3. The request preferably includes a cryptographichash computed from the set of request parameters (acting as a digitalsignature), but the request may alternatively include individuallyencrypted request parameters if the parameters are determined to containsensitive data. The server is preferably a third party server and, morepreferably, the server is running a web application. The request ispreferably sent to a server over a network. In one variation, therequest is sent to a local server on a local area network. In anothervariation, the request is sent to a server running locally on the deviceoriginating the call. In yet another variation, the request may be sentto multiple servers. The request preferably encapsulates at least aportion of the state information from the initiated telephony session,such as the originating phone number, the dialed phone number, the dateand time of the call, geographic location of the caller (e.g. country,city, and/or state, zip), and/or the unique call ID. The request, morepreferably, encapsulates all the state information of the call, but mayalternatively include no state information or partial state information.The state information from the initiated telephony session is preferablysent via HTTP POST in the request body, HTTP GET in the request URI,HTTP header parameters to mimic the data flow of a web browser, or byany combination or suitable alternative way. If new state information isgenerated in the course of the operation of the call router, a requestto the application server is preferably made to communicate the newstate and to request new telephony instructions. Preferably, new stateinformation is not kept or acted upon internally by the call router, butis passed to the application server for processing. Alternatively,partial state information is preferably stored on the call router untila fully updated state is achieved, and then communicated to theapplication server. For example, the application server may specify thatmultiple digits should be pressed on the keypad, not just one, beforenew call state is derived and communicated to the application server. Inone variation, the information from the initiated telephone session maybe a web-form submission included in the HTTP POST request. The requestmay include any state information from the telephony session, such asthe originating phone number, the dialed phone number, the date and timeof the call, and/or the unique call ID, the current status of the phonecall (pending, in-progress, completed, etc.), or the results of atelephony action, including Dual Tone Multi Frequency (DTMF) digitprocessing, or a representation of or a link to a sound recording, orthe status of the last command, or other call state. Examples of a HTTPGET request, a HTTP POST request, and a HTTP GET request are shown inFIGS. 4A, 4B, and 4C, respectively. Further examples of HTTPcommunication used for SMS messaging are shown in FIGS. 4D, 4E, and 4F.The HTTP request (or any suitable request communication) to the serverpreferably observes the principles of a RESTful design. RESTful isunderstood in this document to describe a Representational StateTransfer architecture as is known in the art. The RESTful HTTP requestsare preferably stateless, thus each message communicated from the callrouter to the application server preferably contains all necessaryinformation for operation of the application server and responsegeneration of the application server. The call router and/or theapplication server preferably do not need to remember or store previouscommunications to be aware of the state. Documents, media, andapplication state are preferably viewed as addressable resources,combined with data provide to the resource via request parameter, suchas HTTP GET or HTTP POST parameters, or request body contents. Suchrequest data may include an updated representation of the call resource,or other call state data generated as a result of call router operation,such as digits pressed on the keypad or audio recordings generated.State information included with each request may include a unique callidentifier, call status data such as whether the call is in—progress orcompleted, the caller ID of the caller, the phone number called,geographic data about the callers, and/or any suitable data. However, avarying level of a RESTful communication (statelessness) may be used,such as by using cookies, session tracking, or any suitable devices tosimulate a normal website visitor model. Preferably, data sent with eachrequest may fully enable the application server to determine the nextstate of the call to execute. RESTfulness preferably does not precludeusing external datasource, such as a database, to lookup additional datato log call meta data, or determine application logic.

Step S6 functions to verify the digital signature of the requestparameters. As shown in FIG. 13, after the request is received at theserver, the request parameters are preferably checked and/or parsed fora hash. The cryptographic hash is preferably included in the URL of anHTTP request, but may alternatively be included in the HTTP header ofthe request. If the request does not include a hash, and the webapplication server has enabled the hash function checking as a securitymeasure, the request is preferably determined to be fraudulent, whichwould include—for example—malicious requests, mis-routed requests,corrupted requests and any other requests not intended for theapplication server. If the set of request parameters includes a hash,the hash is preferably extracted from the request, and the secret key ofthe customer web application (i.e. the same key that is stored on thecall router as the customer account secret key) is preferably used togenerate a server side cryptographic hash of the parameters received.The server side cryptographic hash is preferably compared to the hashincluded with the request and if the hashes do not match, the request ispreferably determined to be fraudulent. However, if the server sidecryptographic hash matches the request hash, the request is preferablydetermined to be authentic and ready for further processing at theapplication server. In the variation mentioned above in Step S4, wheresensitive parameters may have been encrypted using the secret key, StepS6 preferably includes decrypting the sensitive parameters. Theapplication server and the third parties operating the application arepreferably responsible for completing this verification step, but theverification may alternatively be completed by a single party, such aswhen a single party operates the application server and the call router.The application server may alternatively be configured to ignore a hashincluded with the request parameters if request authentication is notimportant to the application.

Step S7, which recites processing the request corresponding to the stateof a telephony session, functions to perform processing functions on atleast a portion of the data included in the request. The processingfunctions are preferably performed on a third party server. Theprocessing functions may include recording the data included in therequest and/or metadata about the call session, routing to another URI,performing a database lookup of at least one portion of the dataincluded in the request, voice recognition processing, or any othersuitable processing function. The processing functions may re-use logicand data from other business applications, such as customer databasesand/or shopping cart applications, which may be linked using caller-idor caller provided information. State information is preferablycommunicated with each request from the call router, and applicationstate is preferably not required on the application server.Alternatively, the application server may store state between eachrequest related to the call, by using HTTP cookies, sessions, and/ordatabase records. In some cases, such as the case of a static HTML pagerunning on a server or a stored media file such as an mp3 or way filestored on a server, Step S7 may be simplified, and a file mapped to diskby the URI may be simply returned.

Step S9 recites receiving a response from the server. This response ispreferably an HTTP response. The response is preferably sent as XML,audio binary, or raw text, but may alternatively be any sort ofmessaging format, including HTML, delimited text, key/value text orbinary encoded format. The HTTP response preferably includes directionsto perform telephony actions. The response may alternatively oradditionally include a new URI or a new URI template to use with thetelephony action in Step S3. An additional example XML response is shownin FIGS. 5A and 5B.

1B. Processing Telephone Instructions

The step of processing telephone instructions with a call router S120preferably functions to convert the server response into telephonyactions or executable operations during a telephony session. Thetelephony actions may include, for example, playing a pre-recorded soundfile at a server-specified URI (such as a static mp3 file located athttp://demo.twilio.com/myapp/1234.mp3), reading text to the caller usingtext-to-speech technology, calling another number (such as creating anew voice connection through the PSTN, SIP/VoIP, or other IP technologysystem), collecting digits via DTMF input, recording voice responseaudio, TTY or other inputs, sending an SMS message, or any suitablecombination or sequence of these or other suitable actions. Thisconversion of the server response is preferably performed at a callrouter. Preferably, Step S120 includes processing the responsemime-types associated with the server response. For example, if theresponse mime-type is XML, it is considered to be a set of call routerinstructions. If the response mime-type is MP3, it is considered a soundfile to be played for the caller. If the response type is plain text, itis considered to be text to be read, via Text-To-Speech, to the caller.

Contents of the server response, such as an XML document, are preferablyconverted into a telephony action by processing the documentsequentially (e.g. line by line). Telephony instructions are preferablycontained within the document in the form of a markup language, such asXML as shown in FIGS. 5A and 5B. This sequential approach to processinga document of telephony instructions is enabled when the communicationis stateless and all the necessary information is contained within theURI. This stateless communication preferably allows telephonyinstructions (verbs or commands) to be used as the programming interfacefor a server application performing telephony services. Algorithmicinterpretation (based on the state of the communication) of thetelephony verbs or the document is preferably not necessary. Thetelephony actions are preferably executed in the order of telephonyinstructions found in the contents of the server response. For example,an XML document may include the necessary verbs to carry out thetelephony actions of reading text to a caller, monitoring keys pressedby the caller, and redirecting the caller to a new URI using the pressedkeys as part of the data within the new URI. Preferably, the telephonyaction (such as digits pressed) results in new state information, whichmay result in a repetition of some steps of the method, preferablybeginning at Steps S3. The next URI is preferably provided by the serveras part of the processing instructions. In another variation, the lastURI is reused if the server fails to specify a next URI. In yet anothervariation, no repetition occurs if the server fails to specify a nextURI, and processing continues below at the next call router instruction.The behavior may be determined by the nature of the call routerinstruction; for example, instructions that generate no new stateinformation would not need to have a next URI since they don't triggercommunication with a remote server. More preferably, the telephonyactions result in the repetition of step S3 with the new URI resultingfrom Step S11, but may alternatively initiate a repetition of one ormore steps (Steps S5, S7, S9, or S11) of the method. Step S3 ispreferably repeated using all new phone session state informationresulting from execution of a telephony action, such as digits pressed,a recorded audio file, or the success or failure of any telephony actionrequested. Repetition also includes all state information that remainsrelevant during the course of the session, such as Caller, Called,unique Call ID, and call status. The state information may also berepresented in the form of a URI Template. For example, if the serverresponse specifies that the call router should collect DTMF digits, andspecifies that the next URL is the URI Templatehttp://demo.twilio.com/foo.php?digits={Digits}, and the caller presses1234, the resulting URI is http://demo.twilio.com/foo.php?digits=1234.Similarly, if the server response specifies the URI Template:http://demo.twilio.com/myapp/{Digits}.mp3, the resulting HTTP Requestcould be to a static mp3 file located at:http://demo.twilio.com/myapp/1234.mp3. Thus, a call may be controlled byone server that issued the telephony instruction and a second serverthat processes the response, as shown in FIGS. 13 and 14. Such callcontrol hand-offs constitute the transfer of state information betweenservers in the form of a URI and accompanying request data, such as GET,POST, and/or request body. Preferably, all state communications conformto a syntax established by the call router to facilitate integrationbetween multiple servers. For example, digits pressed on the keypad arepreferably communicated to application servers in an identical fashion,thus minimizing the need for coordination between a multiple applicationservers with regard to how state is transferred. Alternatively, callrouter instructions may dictate the method of communicating new stateinformation, such as the names and types of variables to sendrepresenting new state.

1C. Creating Resources Accessible by a Call Router API

The step of creating call router resources accessible through anApplication Programming Interface (API) S130 preferably functions toexpose information and/or functionality of the call router. Theinteraction from outside parties is preferably performed via the API(call router API). The Call Router API may additionally cooperate withthe use of telephony instructions to function as a storage and retrievalformat for data generated or required by the call router's operation.The Call Router API is preferably an application programming interface(API) such as a REST API (Representational State Transfer) as is knownin the art, but the Call Router API may alternatively be a SOAP (SimpleObject Access Protocol) API or any suitable programmatic communicationinterface. The Call Router API preferably may be used by an applicationasynchronously to the execution of a call (such as to later query thecall records or retrieve recordings). Alternatively, the Call Router APImay be used synchronously during the course of a call (such as to alterthe state of the call, hanging up a call, initiating call recording,etc.). The Call Router API preferably stores state information in apersistent URI for a resource. The persistent URI preferably containsall the necessary state information, and this preferably makes datapersistent, queryable, and recoverable. The Call Router API ispreferably used for modifying resources to alter state of call routerand for interacting with media of the call router. An application servercan use the Call Router API to preferably query meta-data of callrecords, caller identification, call media (such as recordings, texttranscripts, etc.), account information, transfer or interact within-progress communications in the call router, and/or any suitable datagenerated by or required to operate the call router. The Call Router APIpreferably involves communication between an application server and acall router, but may alternatively be communication from any suitabledevice to the call router. The Call Router API preferably resides on thesame hardware as the call router, but may alternatively reside on remotehardware or on any suitable hardware environment. The communication ispreferably HTTP, but alternatively HTTPS or any suitable communicationprotocol may be used. The Call Router API may additionally be compatiblewith any HTTP client. The telephony system of the preferred embodimentpreferably implements a Call Router API that includes a Call Router APIrequest format, a Call Router API response format, and a plurality ofAPI Resources representing types of data generated by or used by theCall Router.

The Call Router API request of the preferred embodiment functions as acommunication message sent from an application server to an API resourceof the call router. The Call Router API request is preferably sent froman application server to a call router, but may be sent from anysuitable device to the call router. The Call Router API request ispreferably similar to a REST API request, but the Call Router APIrequest may alternatively conform to any suitable programming principle,such as SOAP. The Call Router API request preferably uses HTTP tointerface with a resource, but HTTPS or any suitable communicationprotocol may be used. Preferably the HTTP or HTTPS method of GET is usedto retrieve a resource or resource information, and the HTTP or HTTPSmethod of PUT or POST is used to create or update a resource. In somecases, PUT or POST may be used to affect the functionality of the callrouter by modifying the state of a resource. Alternatively, a methodparameter may be included in the URI of the resource to identify arequested action for the resource, or any suitable commands or methodsmay be used to interface with an API resource. The Call Router APIrequest preferably includes authentication such as basic HTTP or HTTPSauthentication, by including message authentication information in theURI, such as a cryptographic hashing of the request content using ashared key, or by any suitable method.

The Call Router API response of the preferred embodiment functions as acommunication sent in response to a method performed on an API resource.The Call Router API response is preferably sent from the call router toan application server, or any suitable device. The Call Router APIresponse is preferably sent in response to a Call Router API request,and the response is preferably sent to the originating device. The CallRouter API response is preferably similar to a REST API response, wherethe response is a representation of the requested resource. The CallRouter API response may alternatively conform to any suitableprogramming principle such as SOAP. The Call Router API response ispreferably returned as formatted XML with information corresponding tothe HTTP status code, a message, error codes, and/or any suitableinformation related to the resource. The Call router API response mayalternatively be represented as Comma-separated values list (CSVs),HTML, JSON, or any suitable format. In one variation, the responseformat is determined by a portion of the requested URI, such as a fileextension. In one variation, an API resource may be a binary dataresource, and the Call Router API response is preferably formatted in anative binary format (e.g., a way or mp3 audio file), an XML meta-datadescription, and or any suitable format.

The API resource of the preferred embodiment functions as an addressablerepresentation of call router meta-data, internal call router state, orthe state of a given resource used by the call router. An API resourceis preferably addressed by a persistent URI. Preferably, the APIresource responds to at least one HTTP action of POST, PUT, GET, orDELETE. The API resource may alternatively respond to multiple HTTPactions. The API resource may alternatively respond to any suitablemethod(s) that are preferably included in the Call Router API request.Consistent with the RESTful conventions, a GET request of a resource mayreturn the current state of a resource, while PUT may update the state,PUT or POST may be used to create a new resource, and DELETE may be usedto destroy a resource. The call router API may alternatively be used toaffect the functionality of an in-progress call in addition to modifyingdata. The API resources of the preferred embodiment include an accountresource, caller ID resource, incoming address resource, call resource,media resource, and/or any suitable resource of the call router. The APIresources may alternatively be any suitable combination of the listedresources or other suitable resources. An API resource is preferably apreconfigured (or “static”) resource, such as account information, or aresource actively in use by the call router, such as a phone call.Modifying the state of a resource via the API may additionally affectthe operation of the call router in real-time, affect the state orcapabilities of the call router in the future, and/or have any suitableeffect.

The account resource of the preferred embodiment functions to allow anapplication to retrieve and/or modify account information. An account ispreferably created by a telephony service provider, such as the operatorof the call router. Information such as account name, usage information,contact information, initial URI, setup parameters, or any suitableaccount information may be retrieved or edited by an application usingthe account resource.

The caller ID resource of the preferred embodiment functions to allow anapplication to retrieve, modify, register new caller ID's (phonenumbers), and/or delete caller identification information. The calleridentification information is preferably for the phone number associatedwith out-going calls made by an application and/or user (i.e. where theapplication appears to be calling from). The numbers for outgoing callsare preferably assigned or verified prior to being used as a caller ID.As an alternative, to prevent fraudulent use of caller ID phone numbersin applications, a verification step may be used by the API beforeadding a new caller ID resource. A request to add a caller ID may beinitiated via a request to the API, wherein a random validation code isgenerated and returned in the API response. The validation code ispreferably provided to an end user. A phone call is placed to the givenphone number (caller ID), requesting that the validation code be enteredvia keypad digits or spoken. Entry of the validation code verifiespossession of the phone number, or the device associated with the phonenumber, at the time of the request. Use of the caller ID resource mayadditionally be presented in a user interface, such as a web browser, bydisplaying the verification code. User interface may be provided by theoperator of the call router, or may be provided by any suitableapplication using the API. Any suitable method may also be used forverification of a caller ID. In another alternative, where multipleparties are involved in a call, the caller ID of one of the existingparty members may be assigned for additional outgoing calls during thatcall session.

The incoming address resource of the preferred embodiment functions toallow an application to get, modify, or provision new inbound DID phonenumbers, SMS short codes, SIP Addresses, etc. for use with applications.PUT or POST may be used to set the initial URI associated with theinbound address. DELETE may be used to release the resource. Theincoming address resource may be used for real-time provisioning ofphone numbers or other addressable inbound identifiers.

The call resource of the preferred embodiment functions to allow anapplication to get or modify the state of a telephony session in thecall router. A telephony session or call may be in-progress, completed,failed, not yet initiated, and/or in any suitable call status. A callresource can preferably change the state or connection of an in-progresscall. State changes preferably include: hanging up or terminatingexisting telephony sessions, transferring one or more existing telephonysessions from one contextual group of sessions to another, merging orsplitting an existing group telephony sessions, transferring one or moretelephony sessions from one communications medium to another (such asfrom one URI to a second URI), injecting an event or notification into aexisting session or group of sessions, recording or ceasing to recordthe audio from one or more parties on a call, and/or any suitable callaction. Call information or call log data can preferably be retrieved bysending a GET to the call resource or by alternatively sending anysuitable method. Outgoing calls may also be initiated by using a POST orany suitable method that preferably indicates that a new call resourceis to be created. When using the call resource to initiate a call,information may be provided as required to place a phone call, such as acaller ID to present, a phone number to call, and/or a URI to handle thecall, but alternatively any suitable information may be provided. A callinstruction XML document may alternatively be provided to the APIinstead of a URI, which is to be used for call instructions. The CallRouter API may additionally respond with the status of a call such as ifthe call is answered, if a machine answered the phone, busy signal, noanswer, call failure, and/or any suitable call status. The response mayalternatively indicate that the new call request was accepted, but hasnot yet been initiated. In the example shown in FIG. 6, callerinformation and caller ID are included in a POST request to the callresource. This step would initiate an outgoing call to the phone numberdesignated in the caller information. The Call Router API responseincludes available state information regarding the call, such as whetherthe call has commenced yet, the call start time, end time, price, callerinfo, and the Call Router API response could alternatively include anysuitable information. Additionally, information about the call returnedat any point by the API may depend on the status of the call. Forexample, a call start time would not be given if the call has not yetbegun, or the call end time, duration or price would not be given if thecall had not yet ended.

Additionally or alternatively, the call resource of the preferredembodiment may be used to transfer a call to a new URI by a single callresource receiving a POST, PUT, and/or any suitable method. In thisalternative, a call is preferably transferred to the new URI for newcall instructions. The API may preferably be used to issue asynchronouschanges in call state, unlike the synchronous communication between thecall router and application server for synchronous URI requests andresponses. The call resource, in this alternative, functions to allow acall to be asynchronously directed to URIs. Examples of variousapplications of the call resource include initiating a new telephonysession, terminating an existing telephony session, call waiting, callholding, call queuing, call parking, private call sessions within aconference, carry on multiple call sessions, and/or any suitableapplication. Any situation where asynchronous events affect the callstatus, such as a call agent becoming available, or a person returningto the phone after placing a caller on hold. The currently executingcall router instruction may be allowed to complete, or may beimmediately terminated, before requesting the provided URI. New callstate resulting from the last call instruction executed by the callrouter, such as digits pressed on the keypad or audio recorded from thecaller, may be provided to the new URI in a form POST or GET parameters,or may alternatively be discarded by the call router and not provided.As shown in FIG. 15, call waiting may be implemented by an applicationsending a Call Router API request to the call resource that POSTs a newURI for the call. The caller is then directed to the new URI forinstructions. A second Call Router API request is sent to the callresource that POSTs the original URI for the call, and thus brings thecaller back to the first call session. The call resource mayalternatively be used in any suitable application.

As an alternative embodiment of the call resource, a calls resource mayimplement a plurality of individual calls as distinct subresources. Forexample, a URI ending in “/Calls” may be a list of many calls performedby the account, and a URI ending in “/Calls/12345” may represent onespecific call, uniquely identified by the key “12345”. The callsresource preferably allows retrieval of many call records and/orcreating new calls, while a single-call resource represents a singlecall. The calls resource preferably accepts a request to create a newcall resource, as is common in RESTful architectures, which in the CallRouter API, preferably serves to initiate one or more new calls. A callsresource may be used to both list current and previous calls using theGET method, as well as initiate a new outbound call using the POSTmethod. Using RESTful principles such as POST or PUT to alter the stateof an individual call resource can preferably change the state of anin-progress call, affecting the realtime activities of the call, such asby hanging up, transferring control to a new URI, joining the call withanother call, or any suitable telephony action.

The media resource of the preferred embodiment functions to allow anapplication to retrieve and/or access information of media stored,cached, created, and/or used during a call. In one variation, the mediaresource is preferably a recording resource to access information andrecordings made during a call via recording call instructions, orasynchronously via the Call Router API. In another variation, the mediaresource may alternatively include call transcripts, text messages, keypress logs, faxes, a binary-coded resource, and/or any suitable media.The media resource may alternatively include a URI of the binary-codedfile (such as a way, mp3 audio file or PDF document file). In onevariation, the media resources may additionally be integrated with thetelephony instructions (or markup language) such that a telephonyinstruction may instruct the call router to perform an action thatcreates a media resource. The call router preferably sends a response tothe application server with the URI of the created media resource. Forexample, when the call router is instructed to record a message, thecall router preferably sends a response to the application server with aunique URI of the recorded message within the API. The media URIpreferably responds to GET requests to return the media in a number offormats, such as binary or XML meta-data representations. The mediaresource may accept requests to delete a media resource. In onevariation, the media resource preferably requires authentication toaccess the resource. In another variation, the media resource may notrequire authentication to enable URI embedding in a variety ofapplications, without exposing authentication credentials. In yetanother variation, authentication is preferably performed viacryptographic hashing, such that credentials are not exposed to clientapplications that consume the media resources. In another variation, themedia resource allows the initiation of transcription of audio resourcesto text using transcription technology. The audio resource used fortranscription is preferably generated during telephony sessions (such asby using the record instruction) and hosted on the Call Router API. Themedia resource preferably allows retrieving or deletion of audiotranscriptions generated from recorded media. The media resource mayadditionally allow centralized hosting of media files, and the resourceURIs are preferably exchanged between the call router and theapplication server, instead of the large media files themselves. Themedia resource may alternatively be used for any suitable media.

Additionally or alternatively, a join resource of the preferredembodiment may be used to join one or calls into a shared session thatallows the parties to communicate (i.e., a conference) by a single callresource receiving a POST, PUT, and/or any suitable method. In thisalternative, one or more calls are preferably join together such thatthey are in a conference. The join resource may alternatively be asubresource or part of the call resource.

Additionally or alternatively, a split resource of the preferredembodiment may be used to split shared sessions (e.g., a conference)into individual call sessions by a single call resource receiving aPOST, PUT, and/or any suitable method. In this alternative, one or moreshared sessions involving two or more calls are preferably split suchthat one or more calls are split into separate calls or into on or moreseparate conferences. The split resource may alternatively be asubresource or part of the call resource.

2. System for Handling Telephony Sessions

As shown in FIGS. 2A, 2B, 3A, and 3B, a system 20 and 30 of thepreferred embodiment for handling telephony sessions includes a callrouter 22, a URI 23 for an application server, a telephony instruction27, and a call router resource 29. As shown in FIGS. 2A and 2B, a firstconfiguration 20 is initiated by a telephony device (such as a telephonecall, fax or SMS message). As shown in FIGS. 3A and 3B, a secondconfiguration 30 is initiated by an application developer side (i.e.,server 26 calling out). The telephony system of the preferred embodimentpreferably additionally implements a Call Router API 28 that includes aCall Router API request format, a Call Router API response format and aplurality of resources substantially similar to those described above.

The call router 22 functions to initiate or receive calls from thetelephony device and connect to a web-application server. The callrouter 22 is preferably connected to a PSTN device over the PSTNnetwork, such that it can receive and make calls from PSTN-connecteddevices 21, such as landlines, cellular phones, satellite phones, or anyother suitable PSTN-connected devices, as well as non-PSTN devices, suchas Voice-Over-Internet-Protocol (VOIP) phones, SIP devices, Skype,Gtalk, or other Internet addressable voice devices. The call router 22may alternatively or additionally function as or include a messagerouter for use with SMS messages. The call router 22 can preferablyconnect to an SMS network, such that it can receive and send messagesfrom SMS network devices 21, cellular phones, computers, smartphones, orany suitable SMS network devices. The call router 22 may also send orreceive text messages, multimedia messages, emails, faxes and othersuitable PSTN-compatible communication messages. The call router 22preferably communicates with the application server 26 using anapplication layer protocol, more preferably using the HTTP, or secureHTTPS, protocol. The communication between the application server 26 andthe call router 22 is preferably stateless and any state information(e.g., call state) or data is preferably located in a URI or the requestparameters, such as HTTP headers, GET URI parameters, POST request bodyparameters, or HTTP cookies. Available state information is preferablytransmitted by call router requests to the application server forstateless processing, and the application server preferably stores nostate. Alternatively, the application server preferably stores localstate information, such as databases or sessions, as is common in webdevelopment. The call router 22 preferably stores state information incall router resources 29. The call router resources 29 are preferablyaccessible by the application server 26 and other devices through thecall router API 28. The call router resources 29 are preferably similarto those described above. The call router 22 preferably associates eachincoming phone number with a starting URI 23, more preferably the URI 23is provided by the application server 26, still more preferably the URI23 is provided by the application developer before a call is received atthe call router 22 by associating the initial URI with the incoming calladdress (such as DID, SIP address, etc.) or by the application uponinitiation of an outgoing call. The call router 22 preferably sends calldata such as the caller number (obtained via Caller ID), callergeographic data (country, city, and/or state, zip) the number dialed,the time of the call, or any other suitable information or parameter.The call data is preferably digitally signed with a secret key 25 storedon the call router 22. A cryptographic hash of the information ispreferably included along with the information as a digital signature.The call router 22 may also encrypt sensitive information (either beforeor after the cryptographic hash is computed) using the secret key toallow sensitive information to be sent across the network. The call datais preferably sent as an HTTP POST request to the application server 26.Call data may also be sent in URL (GET) variables, or encapsulated inHTTP headers. An example HTTP request containing the information in theheader is shown in FIGS. 4A and 4D. As shown in FIG. 4B, further inputs(such as voice recording or DTMF button pressing) from the PSTN-devicemay be subsequently submitted to the application server 26 as HTTPrequests (GET or POST). As shown in FIG. 4C, the inputs from a phonekeypad may be included in an HTTP GET request. As shown in FIG. 4E, thecontent of an SMS message received by the call router may be sent to theapplication server 26 as an HTTP request. As shown in FIG. 4F, theinputs from the text message are included in an HTTP GET request. Therequest data may alternatively be simultaneously sent in the URI (querystring), message body (POST) and message headers, or any combination ofthe above.

The application server 26 functions to provide data processing logic forrequests received from the call router 22. The application server 26 ispreferably connected to the call router 22 via a network 24, morepreferably via the Internet. The application server 26 is preferably athird party server operated outside of the system, but the system mayalternatively include the application server 26. The URI 23 ispreferably associated with an application server 26 or an application onan application server 26. The application server 26 preferablycommunicates with the call router 22 using an application layerprotocol, more preferably using the HTTP protocol, or more secure HTTPSprotocol. The application server 26 preferably receives HTTP requestsfrom and sends HTTP responses to the call router 22. The applicationserver 26 preferably runs on a standard stack of programming languages,hosting providers, operating systems and databases to handle HTTPrequests, as if the caller were a website visitor in a web browser. Theapplication server 26 also preferably verifies the digital signatures ofthe call data received in the requests using the secret key to compute acryptographic hash from the received information and the hash received.If the computed hash and the received hash do not match, or no hash isreceived with the request, then the application server 26 preferablydetermines the request is fraudulent, and the request is preferablydiscarded. If the computed hash and received hash match, the applicationserver 26 preferably determines that the request is authentic andproceeds further with the processing of the request. The applicationserver may alternatively choose to ignore the hash if security is notimportant. The application server preferably uses call state datacommunicated by the call router request to determine the next callrouter instructions, without requiring call state stored on theapplication server. The application server may alternatively use callstate data sent by the call router, such as the caller ID of the calleror the unique ID of the call, to reference additional or external statedata, such as rows in a database or session data stored on theapplication server. The application server 26 preferably responds toHTTP requests received from the call router 22 by generating telephonyinstructions 27 for the call router 22. The application serverpreferably replies to the call router in XML, however, any suitablemachine-readable message format may be used, including HTML, key/valuepair text, delimited text or binary encoding. The XML preferablyincludes the telephony instructions 27 for the call router 22 such asconnecting to another number, playing a recorded greeting, reading text,and/or requesting DTMF digit entry from the caller. The telephonyinstruction 27 may alternatively be related to SMS messaging, MultimediaMessaging Service (MMS) messaging, email, or any suitable messagingtask. The telephony instruction 27 may additionally be used to send anoutgoing SMS message, arrange a phone call from a specific phone number,arranging for a callback, setting up a conference call (connectingmultiple numbers), sending an email, interfacing with a calendar orscheduling system, purchasing goods, or services, or any other suitableinstruction. The XML instructions are preferably a set of commands to beexecuted in order, one at a time (i.e., sequentially). An example XMLresponse is shown in FIGS. 5A and 5B. In single telephony session (e.g.one initiated by a PSTN-device or an SMS device) a response from anapplication server can initiate an outgoing telephony call and/or a SMSmessage. That is, a single XML response preferably provides the abilityto interact with both the SMS network and the voice telephony network(PSTN, SIP/VoIP, etc) sequentially or simultaneously. In addition, audioor video files sent to the call router 22 can be converted to text by anautomatic speech-to-text engine, human or other technique, and sent backin text form as an SMS message or an attachment to an MMS. In onevariation, an application running on a server may be a simple static XMLpage and static sound files, deployed on basic web servers where nodevelopment or scripting environment is available. This variationpreferably uses URI Templates (a current IETF proposal for HTML5), whichessentially includes URLs with placeholders for variable data, likethis: http://www.twilio.com/audio/{Digit}.mp3 where the call router 22would substitute the digits pressed for the {Digit} placeholder in theURI Template, GET the file at the resulting URI, and play the staticsound file in response. This allows an entire application to be authoredoffline in a What-You-See-Is-What-You-Get (WYSIWYG) html editor. Forexample, if the server response specifies the URI Template:http://demo.twilio.com/myapp/{Digits}.mp3, and the caller presses digits1234, the call router 22 would GET the static mp3 file located at:http://demo.twilio.com/myapp/1234.mp3 and play it to the caller. Thevariables used for substitution in the URI Templates preferablycorrespond to the names of variables defined for state submission inHTTP GET, POST and/or header requests from the call router. From theprevious example, {Digits} would be associated with a parameter named“Digits” that is preferably generated as a result of a “gather”telephony instruction (collection of DTMF digits). In the preferredembodiment for the second configuration, the call is initiated by theapplication server 26 (through the call router 22), and the secondconfiguration 30 is substantially similar to the first configuration 20,such that the call routing is preferably handled identically to anincoming call, namely via URI requests from call router 22 to the server26 upon call state changes. The application server preferablyadditionally is able to make calls to the Call Router API as describedabove.

3. Example Applications

Call router applications are preferably web applications, implementingthe most common phone system features with full APIs for administration.Each Call Router Application object has a unique URI. A call may betransferred to that object instance by specifying its URI as a calldestination. The call router applications preferably include: theAutoAttendant application (in FIG. 7), the Follow Me application (inFIG. 8), the Conference application (in FIG. 9), the AutoConferenceapplication (in FIGS. 9-11), the Device application, the Personapplication, the VoicemailBox application, the Group application, andthe Queuing application (in FIG. 12).

The AutoAttendant application, as exemplified in FIG. 7, plays arecorded greeting, and waits for the caller to press one or more digitson the keypad. Based on the input, the AutoAttendant preferably directsthe call to another AutoAttendant, one or more of phones of a person, avoicemail box or any other valid calling destination.

The Follow Me application, as exemplified in FIG. 8, enables a person tobe reached at multiple devices, such as a work number, a cellular phonenumber, a landline, and/or a VOIP device. The Follow Me Applicationpreferably calls these devices in order or simultaneously in an attemptto reach the person.

The Stay With Me application enables a person to transfer an in-progresscall between multiple phone devices, such as a cellular phone and a homephone. For example, a user may wish to transfer a call from a moreexpensive cellular call to a less expensive landline phone, or may wishto transfer a call to a landline phone if a cellular phone battery isrunning low.

The Conference application, as exemplified in FIG. 9, preferably allowsthree or more callers to participate in a call simultaneously, whileproviding mechanisms to control who can join and speak during the call.The Conference application may alternatively or additionally incorporateSMS messaging control. The Conference application upon receipt of an SMSmessage including multiple phone numbers, may initiate a conference callto one or more parties, using the single SMS.

The AutoConference application preferably allows a conferenceadministrator to initiate a conference call with two or more parties byperforming one action, such as selecting a button on a website,selecting a button on a phone device, dialing a phone number, orscheduling the call prior to its initiation. Examples of theAutoConference application implemented using the preferred method of theinvention are shown in FIG. 9 (viewed from the PSTN-device side), FIG.10 (viewed from the application server side), and FIG. 11 (initiated byan application server using the call router API).

The Device application represents a telephone used within the phonesystem, and may be a hard phone (hardware) or soft phone (software), aVOIP phone or a traditional PSTN phone. The Device application handlesconfiguration details and device status (Do Not Disturb, Busy, etc.).

The Person application represents a human-being user of a telephonesystem. The Person may have one or more extensions, devices, and/orvoicemail boxes, and may have a preferred order in which to ring theirphones or voicemail. A person may have a username and password withwhich to login and update these settings.

The VoicemailBox application preferably plays a greeting, and allows thecaller to record a message. Once complete, the recorded message may bestored for later listening, emailed as an audio link or attachment, orboth. A list of current messages for a VoicemailBox may be retrieved bydialing in, via API, via RSS feed, and/or any other suitable method ordevice. In one variation, the audio recording may be automaticallytranscribed, transforming speech to text. The text is preferablyincluded in the email or text message along with the audio link,attachment, and/or retrievable later by any suitable means of the API.

The Group application preferably represents a logical grouping of otherCall Router Application objects, including other Groups. The Grouppreferably defines the behavior of calls directed to the group,including queuing, hunting for the first available party, andsimultaneously ringing multiple parties.

The Queuing application preferably, upon receipt of a phone call or anSMS message, enters the message sender to a telephony call queue and themessage sender is called back via the PSTN, SIP/VoIP network or othertelephony network, as exemplified in FIG. 12. The call may be placedeither at the message' originating number or another pre-specifiednumber, either when a human/operator/service is available (customerservice applications) at a pre-scheduled time, such as a wake-up call,anniversary reminder, birthday reminder.

The call router applications may additionally or alternatively include:

a Busy Signal Buster service that, upon receipt of an SMS message orphone call transmitting a number to be called that is currently busy,and calls the SMS message sender back at the message' originating numberor another pre-specified number when the number is no longer busy;

a SMS Reader/TTY application that, upon receipt of an SMS, translatesthe text into audio, using a text-to-speech engine to a caller or themembers of an audio conference (e.g., to tell them you will join thecall in a few minutes), or for the hearing impaired to use instead ofTTY services;

a Translation application that, upon receipt of an SMS messagecontaining a phrase in a language, translates the language of the SMSmessage into another language (either manually by a human orautomatically by a program) and sends a response message via SMS oremail; and

a Programming application that, upon receipt of an SMS messagecontaining programming code, could compile the code and execute thecode, update a website, update a programming project, return data from adatabase, return a generated computer graphics object as an MMS message,or any other suitable program compilation or computation.

The call router applications may additionally or alternatively include aStatus/Notification application that allows users to get or send thestatus of an object, task, or process by sending an SMS message andreceiving a call back via the PSTN, SIP/VoIP network or other telephonynetwork. The service may be used by an operator sending an SMS messagewith the name of a particular server and then get a call back on hermobile phone and hear the status of that server read aloud. The servicemay also be used for notification, i.e. to call other parties. Forexample, a store manager may want to let employees know what time astore is opening the next day. The manager could send an SMS messagethat would then call each employee and tell him or her over the phonethe time when the store was opening the next day, and or what time theyneeded to arrive at work.

The call router applications may, however, include any collection and/orpermutation or these or other suitable prebuilt telephony functions andfeatures.

Applications of the preferred method may include simple PBXfunctionality, such as auto-attendant voice menus, employee extensions,and voicemail features. The application may also include other,unconventional, applications such as an Interactive Hold application, aConference Calling application, an Independent Music Hold Channel, aVoting/Fundraising application, a Sales Application, a Blog by phoneservice and a Call Annotation application.

The Interactive Hold application preferably includes interactiveactivities, such as a playing a quiz game to be played while on hold(with or without the ability to be played against other callers),listening to news headlines or podcasts of the choice of the listener,and using a phone keypad as a synthesizer to create music in realtime.The Conference Calling application may, as an example, include selectingparticular (or random) users from a phone book and instantlysubstantiating a conference call to the group, with the ability to savethe group for future calling. The Independent Music Hold Channelpreferably allows independent artists to upload, classify, and grantpermission for their works to be played while a caller is on hold. TheVoting/Fundraising application preferably connects willing callers(calling to encourage voting or to raise funds for a cause), topotential voters and/or donors respectively, preferably including aninterface for the caller to display information about the voter/donorand to make notes about the voter's response to the call. The SalesApplication preferably allows sales organizations to quickly integrateinbound and outbound calls with customer relationship management (CRM)applications, or read order details from a shopping cart application.Finally, the Call Annotation application allows call participants toappend meta-data, such as reference URIs used in the phone conversation,to a specific call and a timestamp within the call. Participants on thecall with a suitable user agent could view the annotations during thecall, and people listening to a later replay of the call audio couldalso receive such annotations at the same timestamp during the playback.The Call Annotation may be used, for example, to facilitate conferencecall note taking, employee training, sales team collaboration, and/orcustomer support collaboration.

Applications may alternatively include hold or park functionality, wherea caller is placed in a waiting state until an external event resumesthe call, such as another party becoming available. One variation ofthis application is the call queue, where callers wait for an availableattendant to answer a call. Applications of the preferred method mayalternatively include other conventional or unconventional PBXfunctionality.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims. It is possible, and indeed hoped, that additional applicationswill be designed and built upon this technology platform (the preferredmethod and/or system of the invention) that would not otherwise bepossible using conventional telephony platforms.

1. A method of processing telephony sessions of a network including anapplication server and a call router, the method comprising the stepsof: communicating with the application server using an application layerprotocol; processing telephony instructions with the call router; andcreating call router resources accessible through a call routerApplication Programming Interface (API).